|
In software deployment, an environment or tier is a computer system in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use the ''development'' environment (where changes are originally made) and ''production'' environment (what end users use) are separated, often with several stages in between, in order to allow phased deployment (rollout), testing, and rollback in case of problems. Environments may vary significantly in size: the development environment is typically an individual developer's workstation, while the production environment may be a network of many geographically distributed machines in data centers, or virtual machines in cloud computing. Code, data, and configuration may be deployed in parallel, and need not connect to the corresponding tier – for example, pre-production code might connect to a production database. == Architectures == Deployment architectures vary significantly, but broadly, the tiers are bookended by starting at ''development'' (DEV) and ending at ''production'' (PROD). A common 4-tier architecture is ''development, testing, staging, production'' (DEV, TEST, STAGE, PROD), with software being deployed to each in order. Other common environments include Quality Assurance (QA), for acceptance testing; sandbox or experimental (EXP), for experiments that are not intended to proceed to production; and Disaster Recovery, to provide an immediate fallback in case of problems with production. Another common architecture is development, testing, acceptance and production (DTAP), consisting of dev/test/qa/prod. This language is particularly suited for server programs, where servers run in a remote data center; for code that runs on an end user's device, such as applications (apps) or clients, one can refer to the user environment (USER) or local environment (LOCAL) instead. Exact definitions and boundaries between environments vary – test may be considered part of dev, QA may be considered part of test, part of stage, or be separate, etc. The main tiers are progressed through in order, with new releases being deployed (''rolled out'' or ''pushed'') to each in turn.〔(Traditional Development/Integration/Staging/Production Practice for Software Development )〕〔(Development Sandboxes: An Agile "Best" Practice )〕 Experimental and recovery tiers, if present, are outside this flow – experimental releases are terminal, while recovery is typically an old or duplicate version of production, deployed after production. In case of problems, one can ''roll back'' to the old release, most simply by pushing the old release is if it were a new release. The last step, deploying to production ("pushing to prod") is the most sensitive, as any problems result in immediate user impact. For this reason this is often handled differently, at least being monitored more carefully, and in some cases having phased rollout or only requiring flipping a switch, allowing rapid rollback. Sometimes deployment is done outside of this regular process, primarily to provide urgent or relatively minor changes, without requiring a full release. This may consist of a single patch, a large service pack, or a small hotfix. Tiers can be of very different sizes: dev is typically an individual developer's workstation (though there may be thousands of developers), while prod may be many geographically distributed machines; test and QA may be small or large, depending on the resources devoted to these, and staging can range from a single machine (similar to canary) to an exact duplicate of production. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Deployment environment」の詳細全文を読む スポンサード リンク
|